feat: take all neighbors into account when computing resource digests #713
Conversation
otaviomacedo
temporarily deployed
to
integ-approval
GitHub Actions
Inactive
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #713 +/- ##
==========================================
- Coverage 79.38% 79.34% -0.04%
==========================================
Files 49 50 +1
Lines 7209 7278 +69
Branches 809 821 +12
==========================================
+ Hits 5723 5775 +52
- Misses 1467 1484 +17
Partials 19 19
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Typo? A is different from C ? So we now have two digests. Let's give them names (not the best ones, maybe you can come up with better ones).
If we always use both digests to come up with the mapping digest ( Or would we be better off having a 2-step digest, where we map using the |
otaviomacedo
temporarily deployed
to
integ-approval
GitHub Actions
Inactive
Yes, thanks. Updated.
Right now, this is not a problem because we require the graphs to be isomorphic anyway. But I went ahead and implemented your suggestion, so it's ready when we need it. |
The current definition of the digest of a resource computes a hash of its properties plus the hashes of its dependencies.
But if we have a graph like:
where
BandDare identical, the current algorithm will compute the same digest for them, even ifAis different fromC(and therefore have different digests). This is undesirable, as some cases are considered ambiguous, even if we could very well tell them apart. Real world example:Role1andRole2tend to be identical, but they can nevertheless be told apart because at least the functions will have different properties. So, even if both roles are renamed, for example, we can still provide a valid mapping.This change improves the algorithm by also taking into account all neighbors of a resource for digest computation. It does this by doing a two pass over the graph: first navigating in topological order and computing the digests, then navigating in the opposite order and doing the same. So each resource has two digests, that are in turn, used to compute the final digest.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license